home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 2 / Meeting Pearls Vol. II (1995)(GTI - Schatztruhe)[!].iso / Pearls / dev / TurboM2 / docs / OPTOZS.DOC < prev    next >
Text File  |  1995-01-24  |  4KB  |  111 lines
  1.             Compiler optimizations
  2.             ======================
  3.  
  4.    The compiler applies a few easy to implement optimizations to generate
  5.    small & fast code. The two three (as described below) give the Drystone
  6.    benchmark a considerable speed boost.
  7.    These optimizations increase compilation time, but because the compiler
  8.    compiles itself, the slowdown is more than made up for by the higher quality
  9.    code. The compiler consists of 14000 lines of (dense) code and compiles
  10.    itself in around 60 seconds on a 14Mhz MC68020.
  11.    These optimizations are also performed by the DICE compiler and assembler.
  12.    The commercial M2Amiga compiler used to bootstrap M2C, generates relatively
  13.    slower (and larger) code because it does not attempt to do any of the
  14.    following:
  15.  
  16. Register Allocation
  17. -------------------
  18.  
  19.    Simple local variables and parameters are allocated to registers based on
  20.    wieghted usage.
  21.    Parameters are copied off the stack and into registers at procedure entry.
  22.    Locals used inside nested loops are given highest priority.
  23.    Typically there are 6 data registers (d2-d7) and 4 address registers
  24.    (a2,a3,a5,a6) available.
  25.    Procedures that contain complex expressions may have less registers
  26.    available.
  27.    Low level procedures (that call no others) can also use d0,d1,a0,a1 to hold
  28.    locals.
  29.    Locals that are passed as VAR parameters to other procedures, arguments of
  30.    SYSTEM.ADR or locals referenced from within nested procedures
  31.    (so called non-local,non-global variables) cannot be allocated to registers.
  32.  
  33. LINK/UNLINK removal
  34. -------------------
  35.  
  36.    If the compiler manages to allocate all parameters and variables for
  37.    a particular procedure to registers.Then it can remove the LINK & UNLINK
  38.    instruction pair which normally constructs/destructs a stack frame for
  39.    variables in that procedure.
  40.    If this can be done the procedure call overhead is greatly reduced. This is
  41.    specially important in small procedures eg. when using opaque types we
  42.    are sometimes forced to use a function just to read the contents of a field.
  43.  
  44. CASE statement
  45. --------------
  46.  
  47.    Generating code for the case statements is quite tricky. The compiler must
  48.    adequately cope with a variety of styles:
  49.  
  50.    CASE exp OF
  51.    |-42 : ..
  52.    |10000: ..    (* This is bad style but is still legal.                     *)
  53.    END         (* Some (inadequate) compilers will complain if you try this *)
  54.  
  55.  
  56.    or
  57.    --
  58.  
  59.    CASE exp OF
  60.    |0: ..
  61.    |1: ..
  62.    |2: ..
  63.    |3: .. (* Case labels are contiguous                    *)
  64.    ...      (* This is really what the case statement is for *)
  65.    |100: ..
  66.    END ;
  67.  
  68.    or a combination of the 2 styles.
  69.  
  70.    The algorithm for the case statement is:
  71.  
  72.    If there are only a few case labels (less than 8 say) then perform a linear
  73.    search.
  74.    If the number of case labels is a high proportion (atleat 50 percent say) of
  75.    MAX(label)-MIN(label) then perform a table lookup to see where to branch to.
  76.    Otherwise subdivide the labels (into 2 havles) and recursively apply the
  77.    algorithm.
  78.  
  79.    The compiler generates code to implement this algorithm.
  80.  
  81. Branch Optimization
  82. -------------------
  83.  
  84.    The M68000 provides a 16bit as well as 32bit branch instruction.
  85.    When the compiler generates a forward branch its impossible for it to know
  86.    which to use.To be safe it generates space for a 32bit instruction, if
  87.    subsequently it turns out that only a 16bit instruction was needed, the code
  88.    will contain a 2 byte hole. The compiler keeps track of where these holes
  89.    occur and after code generation compacts all the code.
  90.    Branch optimization typically reduces code size by about 5 percent.
  91.    If you spend a few minutes thinking about it, youll realize that performing
  92.    branch optimization is more complex than it appears.
  93.  
  94. Adressing Models
  95. ----------------
  96.  
  97.    The compiler supports (and defaults to) small data (A4 relative) &
  98.    small code (PC relative) memory models. These models reduce the size of the
  99.    relocation information in the final executable, i.e. its smaller and loads
  100.    faster.
  101.  
  102. Future optimizations
  103. --------------------
  104.  
  105.    The compiler does not implement registerized parameter passing, this may
  106.    be added. It doesn't do any 'global' optimizations either because I dont
  107.    know how :) This is only my second compiler, the first was for a toy
  108.    programming language (at college).
  109.  
  110.  
  111.